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Abstract 
Distributed systems are multi-processor information processing systems which do not rely on 

™LT r 1 !? "If" 10 '" 5 ' f ° r communlcation - This paper presents ideas and techniques in 
modelling distributed systems and its application to Artificial Intelligence. In section 2 and 
3, we discuss a model of distributed systems and its specification and verification 
echniques. We introduce a simple example of air line reservation systems in Section 4 and 
illustrate our specification and verification techniques for this example in the subsequent 
sections. Then we discuss our further work. 
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%• Introduction 

Distributed systems are multi-processor information processing systems which do 
not rely on the central shared memory for communication. The importance of distributed 
systems has been growing with the advent of "computer networks'* of a wide spectrum: 
Networks of geographically distributed computers at one end, and tightly coupled systems 
built with a large number of inexpensive physical processors at the other end. Both kinds 
of distributed systems are made available by the rapid progress in the technology of large 
scale integrated circuits. Yet little has been done in the research on semantics and 
programming methodologies for distributed information processing systems. 

Our main research goal is to understand and describe the behavior of such 
distributed systems in seeking the maximum benefit of employing multi-processor 
computation schemata. 

The contribution of such research to Artificial Intelligence is manifold. We 
advocate an approach to modelling intelligence in terms of cooperation and communication 
between knowledge-based problem solving experts. In this approach, we present a coherent 
methodology for the distribution of active knowledge as a knowledge representation theory. 
Also this methodology provides flexible control structures which we believe are well suited 
for organizing distributed active knowledge. Furthermore we hope to make technical 
contributions to the central issues of problem solving such as parallel versus serial 
processing, centralization versus decentralization of control and information storage, and 
the "declarative-procedural" controversy. 

This paper presents ideas and techniques in modelling distributed systems and its 
application to Artificial Intelligence. In section 2 and 3, we discuss a model of distributed 
systems and its specification and verification techniques. We introduce a simple example of 
air line reservation systems in Section 4 and illustrate our specification and verification 
techniques for this example in the subsequent sections. Then we discuss our further work. 
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2. A Model of Distributed Sy st 

The actor model of computation[Greif&Hewitt75, Greif75, Hewitt&Baker77] has 
been developed as a model of communicating parallel processes. The fundamental objects 
in the model of computation are actor,. An actor is a potentially active pie« of 
knowledge (procedure) which is activated when it is sent a message which is also an actor. 
Actors interact by sending messages to other actors. More than one transmission of 
messages may take place concurrently. Each actor decides how to respond to messages sent 
to it. An actor is defined by its two parts, a script and a set of acquaintances. Its script 
is a description of how it should behave when it is sent a message. Its acquaintances are a 
finite set of actors that it directly knom about. If an actor A knows about another actor 
B. A can send a message to B directly. The concept of an ej^t is fundamental in the 
actor model of computation. An event is an a_rrjval of a message actor M at a target actor 
T and is denoted by the expression (T <= M). A computation is expressed as a partially 
ordered set of events. We call this partial order the •'precedes: ordering. Events which 
are unordered in the computation can be concurrent. Thus the partial order of events 
naturally generalizes the notion of serial computation (which is a sequence of events) to that 
of parallel computation. 

A collection of actors which communicate and cooperate with each other in a goal 
oriented fashion can be implemented as a single actor. In essence actors are procedural 
objects which may or may not have local storage. Some may behave like procedures and 
some may behave like data structures. Modules in distributed systems are modelled by 
actors and systems of actors. In this regard, IC chips can be viewed as actors. 

Knowledge and intelligence can be embedded as actors in a modular and 
distributed fashion. For example, /ra rae5 [Minsky75, Kuipers75], 

«ntt 5 [Bobrow&Winograd76], be ing 5 [Lenat75], S tereot^e 5 [Hewitt75] e.t.c. which 
represent modular knowledge with procedural attach, are modelled and 
implemented as actors. In the context of electronic mail systems and business information 
systems, objects such as forms, documents, customers, mail collecting stations, and mail 
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distributing stations are easily modelled and implemented as actors. 

Messages which are sent to target actors usually contain continuation actors to 
indicate where the result of the receipt of the message should be sent. By virtue of 
continuations in messages, the message-passing in the actor model of computation realizes a 
universal and yet fjexible control structure without using implicit mechanisms such as push 
down stacks. Various forms of control structures such as go-to's, procedure calls, and 
coroutines can be viewed as particular patterns of message passing [Hewitt76]. 

This model of computation has been implemented as a programming language 
PLASM A[Hewitt76]. The script of an actor can be written as a PLASMA program. We 
believe that PLASMA yill provide a basis for programming languages for distributed 
systems. In section 5, an example of PLASMA programs i$ given as a script of a 
flight-data actor in the model of a simple air line reservation system. 

3. Techni ques for Specification and Verification 

In designing and implementing a distributed (message-passing) system, it is 
desirable to have a precise specif ication of the intended behavior <>f the distributed system. 
Also we need sound techniques for demonstrating that implementations of the system meet 
its specification, Belqw we give some of the central ideas of our specification and 
verification techniques based on the model introduced in the previous section. The more 
detailed work will be found in [Yonezawa77]. 

In specifying the behavior of a distributed system, it is not only practically 
infeasible, but also irrelevant to use global states of the entire system or the global time axis 
which governs the uniform time reference throughout the system. We are concerned with 
states of modular components of a distributed system which interact with each other by 
sending messages. Thus we are interested in the states of actors participating in an event at 
the instance at which the message is received. 

In our specification language, conceptual representations are used to express 



jf^S^ 



local states of actors (modules). Conceptual representations were originally developed to 
specify the behavior of actors which behave like data structures[Yonezawa&Hewitt76l We 
have found them very useful to express states of modules in distributed systems at varying 
levels of abstraction and also from various view points. The basic motivation of 
conceptual representations is to aid in providing a specification language which serves as a 
good interface between programmers and the computer and also between users and 
imptem-ntors. Conceptual representations are intuitive clear and easy to understand, yet 
their rigorous interpretations are provided. Instead of going into details of syntactic 
constructs of conceptual representations, we give examples. Below !<exp> is the unpack 
operation on <.xp> which means writing out all elements denoted by <ex P > individually. 

(CELL A) ., . . . . 

{QUEUE ABC) containing A as its content*. 

(NODE (car: A)(cdr: B)) . n &!?*"* ""''' <? -"™" a A ? £■ 

(CUSTOMER (letter,: m)(-oHt amp s-neciei: „), ' SP "^ " nUMmn < A °" d B 

;a customer vi tiling a post office 

(POST-OFFICE (customer: {k}) (collector: {!cl}» M ° "^ *""" |M "* "^ " J '° m ^ 

;o post office which contains customers »c and mail collectors !cl. 

It should be noted that a conceptual representation does not represent the identity of an 
actor. It only provides a description of the state of an actor. Thus to state that an actor Q 
is in the state expressed by a conceptual representation (QUEUE A B C), an assertion of the 
following form: 

(Q i*-a (QUEUE A B C)) 

is used. Some examples of specification using conceptual representation are given in the 
later sections. 

Symbolic evaluation is a process which interprets a module on abstract data to 
demonstrate that the module satisfies its specification. Symbolic evaluation differs from 
ordinary evaluation in that 1) the only properties of input that can be used are the ones 
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specified in the pre-requisites, and 2) if the symbolic evaluation of a module M encounters 
an invocation of some module N, the specification of N is used to continue the symbolic 
evaluation. The implementation of N is not used. The technique of symbolic evaluation 
has been studied by a number of reseachers, for example [Boyer&Moore75, 
Burstall&Darlington?^ Hewitt&Smith75, Yonezawa75, King76l 

Our method for symbolic evaluation of distributed systems is an extention of the 
one developed for symbolic evaluation of programs written in SIMULA-like 
Ianguages[Yonezawa&Hewitt76l One of the main techinques we employ in symbolic 
evaluation is the introduction of a notion of 5jUMMoM[McCarthy&Hayes69I A situation 
is the local state of an actor system at a give moment. The precise definition of locality in 
the actor model of computation is found in [Hewitt&Baker771 By relativizing states of 
modules with situational tags which denote situations, relations and assertions about 
states of modules in different situations can be expressed. Explicit uses of situational tags 
seem to be very powerful in symbolic evaluation of distributed systems. A simple example 
is given in Section 7. 

Another technique we employ in symbolic evaluation is the use of actor 
induction to prove properties holding in a computation. Actor induction is a 
computational induction based on the precedes ordering (cf. Section 2) among events. It 
can be stated intuitively as follows: 

"For each event E in a computation C, if preconditions for E imply 
preconditions for each event E' which is immediately caused by E, then 
the computation C is carried out according to the overall specif ications." 

The precedes ordering has two kinds of suborderings, 1) the activation ordering, "activatc$", 
which is the causal relation among events, and 2) the arrival ordering, "arrivc&-befor<T 9 
which expresses ordering among events which have the same target actor. Thus there are 
two kinds of actor induction according to these suborderings. An example of the induction 
based on the arrival ordering is used in Section 7. 



4. Modelling an Air Line Reservation ,Sy_st_em 

-- A specification of an Air Line Reservation System - 

As an illustrative example of distributed systems, let us consider a very simple air 
line reservation system. Suppose we have just one flight which has a non-negative 
number of seats. A number of travel agencies (parallel processes) independently try to 
reserve or cancel seats for this flight, possibly concurrently. We model an air line 
reservation system as a flight actor F which behaves as follows. The flight actor F accepts 
two kinds of message, {reserve-a-seau) and {cancd-a-tcat:). When F receives 

Iresorve-a-nat:), if the number of free seats is zero, a message { n o-mor<,-s Cat *:) is. returned. 
Otherwise a message {ok-iu-rwrvcd:) is returned and the number of free seats is decreased 
by one. When F receives {cancel-a-seau), if the number of free seats is less than the 
maximum number of seats of the flight, a message {ok-iu-canc.elhd.) is returned and the 
number of free seats is increased by one, otherwise Uoo-many-concoh:) is returned. 
^-s. Furthermore requests by {rexcrve-a-nat:) and {cancel-a-xeat:) are served on a 

first-come-first-served base. 

To write a formal specification of the air line reservation system, we need to describe the 
states of the flight actor. For this purpose, we use the following conceptual representation 

{FLIGHT {seatt-frce: <m» {size: <s») 

which describes the state of a flight actor. The number of free seats is <m> and <s> is the 
size of the flight in terms of the total number of seats. The formal specification of the air 
line reservation system using this conceptual representation is depicted in Figure 1 below. 
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<evcnt: (create-f light <a S) 
<pre-cond: (S > 0) > 
<return: F* > 
<post-cond: (F is-a {FLIGHT (seats-free: S) Uizc: S)))» 

<evcm: (F <= (reserpe-a-seat:)) 
(case-1: 

<pre-cond: (F is-a (FLIGHT (seats- free: 0) (size: $)))> 
<next-cond: (F is-a (FLIQHf (seats- free: 0) (mo: S)))> 
Kreturn: (no-mpre-seats:) >) 
(case-2: 
<pre-cond: 

(F is-a (FLIGHT (scan-free: N) (sim $))) 
(N>0) > 
<next-cond: (F ii-a (FLIGHT (seats-free: N - 1) (me: S)))> 
Kreturn: (ok-its-rescrped:) >)> 

<4iwilt: (F <s (canccl-a-seat:)) 
fcase-1: 

<pre-cond: (F is-a (FLIGHT (scats-free: S) (m<?: S)))> 
<fie*i-cond: (F w-a (FLIGHT (seats-free: 5) (size: $)))> 
<return: (too-many-cancels:) >) 
(casc-2: 
<pre-cond: 

(F is-a (FLIGHT (seats-free: N) (size: S))) 
(N<S) > 
<next-cond: (F **-a (FLIGHT (seats- free: N + 1) (me: S)))> 
<return: (ok-its-cancellcd:) > ) > 

<for-events: E, E' 

tii M E = (F <= M), V * (F <s M') 

(F is-a (FLIGHT (scats-free: ...) (me:..,))) 

(E arrives-before E')> 
<caused-e vents: reply-for[E], reply~for[E']> 
<post-cond: (reply- for[E] precedes reply-for[E']) » 

Figure 1 A Specification of th$ Air Line Reservation System 
(A Specification for the Flight Actor) 

The first <ef;em:..>clause states that % new flight actor F is created by an event 
where the create-flight actor receives a positive number S. <actor>* means that <actor> is 
newly create^. Thf second <0t>em;.,.>-clause has two cases according to the number of free 
seats at the moment when the flight actor F receives (reserve-a-scau). When the number of 
free seats is zero (Caie-i), the st$te of F does not change. When it is positive (Case-2\ the 
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number of free seats decreases by one as stated by the assertion in the <n C *i- co „<f:...>-c1ause. 
The notation in Figure 1: 

Kevcnti (T <= M) 
<pre-cond: ... > 
<next-cond: ... <assertion> ... > 
ireturn; <actor> > > 

meann that when an event (T <= M) takes place, if the preconditions are satisfied, <a«ertion>s 
in the <mxi-cond:..>-d*me hold immediately after the event until the next message arrives 
at T. <actor> in the <r C turn:...>-clause is returned as the result of the event. <ncxt-cond:...> 
differs from <po»t-cond...,> in that assertions in < P o»t-cond : ...>-chuse hold at the time <actor> 
is returned, whereas assertions in <ncxt-cond:...>-chme hold at the time the next message 
arrives. The next message may arrive at T before or after a reply for the previous message 
is returned. The third <evcnt.-...>-clause is for the cancelling event, which is interpreted in a 
similar way. The <for-eventt: ...>-clause states that requests (messages) received by the flight 
actor are served on the first-come-first-served base. Namely, the replying events for events 
E and E' take place in the same order as E and E\ 
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Our strategy to implement the air line reservation system (specified in the previous 
section) is as follows. First, we implement a flight-data actor which satisfies the 
specification in Figure 1 on the condition that it is always activated serially. Then we 
put some protecting (or scheduling) mechanism on the flight-data actor so that the protected 
flight-data actor may satisfy the specification of the air line reservation system. 

In Figure 2 below we give an implementation of the flight-data actor in PLASMA. 



(create-flight-data =*) s 
{let (size initially s) 

(seat6~free jniiioKy a) 
then 

(cases 
(s> (rejerw-a-adat:) 
(rules seats-free 
>>0 

{no-more-seats:)) 
(h> «j/«$ 
(seats-free -i (seats-free - 1)) 
{ok-its-rescrved:)))) 
(s> {cancefca-scat:) 
(rules seats-free 
(=> size 

{too- many-cancel*:)) 
(s> ©Ijso 
(seats-free -f (seats-free + 1)) 
(ofc-ifs-caFice//^:)))) )) 
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,'create-flight-dafa receive* a size s o/ f light. 

;a variable size i* *<»i *o s. 

;a variable seats-free is ii.#»t io s. 

;*&<* following cmm-clause is 

;roturncd a* an actor which behave* a* a flight-data, 

;whcn a {reserve-,.*) message is received^ 

;if seats-free is zero, 

;(ito-...) message is returned* 

otherwise 

jseats-free is decreased by one. 

;{ok~.„) message is returned* 

;when a (cancel-...) message is received, 

;if seats-free is equal to size, 

;{too-.**) is returned, 

tot her wise 

;$eats-free is increased by one* 

;{ok-.**) is returned* 



Figure 



It is fairly straightforward to write a specification for this flight-data FD by using a 
conceptual representation: 

{FLIGHT-D/ITA [seats-free: <m» {size: <s») 



which describes the state of a flight-data actor. The number of free seats is <m> and <s> is 
the size of the flight in terms of the number of seats. Note that if FD were sent more than 
one message concurrently, anomalous results would be caused. For example, in the 
implementation in Figure 2, if (reserve-a-scat:) and {canccl-a-seat.) messages are sent 
concurrently, {no-more-seats:) message might be returned even if there are vacant seats. 
Therefore in order to model the air line reservation system by using the above 
implementation of a flight-data actor, the way it is used must be restricted so that 
interference between different activations does not take place. As suggested in the 
beginning of this section, the restriction we impose is that FD must be used serially in the 
$eme that FD is not allowed to receive a message until the activation by the previous 
message is completed. Now the flight-data actor can be used to implement the air line 
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reservation system under this restriction. We give a formal specification for the 
flight-data actor in Figure 3 below. 

<evenu (create-f light-data <= S) 
<pre-cond: (S > 0)> 
<rcturn: FD* > 
<post-cond: (FD is-a {FLIGHT-DATA (seats-free: S) Uize: S)))» 

<event: (FD <= (reserve-a-seat:)) 
(ca^e-~: 
<prc-cond: 

(FD is-used-serially) 

(FD is-a (FLIGHT-DATA (seats-free: 0) (size: S)))> 
Kreturn: (no-more-seats:) > 

<post-cond: (FD «-a (FLIGHT-DATA (scats-free: 0) («*<?: S))) » 
(case-2: 
<prc-cond: 
(FD is-used-serially) 

(FD iVa (FLIGHT-DATA (teats-free: N) («j«e: S))) 
(N>0) > 
<rclur?t; {ok-its- re served:) > 
<po*t-cow<f: (FD iVa (FLIGHT-DATA (seats-free: N - 1) Uize: S)» »> 

<eMiii: (FD <= (cancel-a-seat:)) 
(case- 1: 
<pre-cond: 

(FD is-used-serially) 

(FD is-a (FLIGHT-DATA (seats-free: S) («*<?: S))) > 
<r«?*urrt: (too-many-cancels:) > 

<post-cond: (FD iVa (FLIGHT-DATA (seats-free: S) («*<?: S))) » 
(case-2; 
<prc-cond: 

(FD i*-uW-j?f?na//y) 

(FD is-a (FLIGHT-DATA (seats-free: N) (size: S))) 

(N < S) > 
<relttrn; (o&-it*-cafic<?//<?ef;) > 
<post-cond: (FD u-a (FLIGHT-DATA (seats-free: N + 1) Cure; S))) »> 

Figure 3 A Specification for the Flight-data Actor 
In this specification, the restriction of the serial use is expressed in the following notation, 

(FD is-used-serially) 

stated as a precondition for events. In contrast to the specification above, there are no such 
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preconditions in the specification of the air line reservation system (the flight actor) in 
Figure 1. Thus the reservation system is specified to work properly even if it is accessed 
concurrently. Also notice that the specification above has no statements about scheduling 
such as the first-come-first-served scheduling which is stated as </or-™*,««:...>-clause in the 
specification of the air line reservation system. 

®» One-at-&-tim« 

In this section, we consider how the serial use of a flight-data actor is realized in 
environments where communicating parallel processes try to use the flight-data actor. Our 
approach is to surround a flight-data actor FD with some mechanism which arbitrates 
parallel requests to the flight-data actor FO and passes these requests to FD in the serial 
fashion. We call this protection mechanism a one-at-a-time guardian. A one-at-a-time 
guardian can be easily implemented by a serial tzer[Atkinson&Hewitt77] which is a 
general synchronization mechanism in the actor model of computation. 

Now we give a specification for one-at-a-time guardians. A one-at-a-time 
guardian is created in an event where an actor one-at-a-time receives a resource (a 
flight-data actor in this case). The one-at-a-time guardian thereby created will then contain 
the received resource. The following <ct*mt:.„>-clause expresses this. 

<evem: (one-at-a-time <= RESOURCE) 
Kreturn: G* > 
<po$t-cond: (G i$-a {ONE-AT-A-TIME RESOURCE)) » 

where (ONE-AT-A-TIME <resource>) is the conceptual representation for a one-at-a-time 
guardian which contains <resource>. Next, we specify how a one-at-a-time guardian G 
behaves. In general a request to the guardian G, which is an arrival of a message M at G, 
eventually causes an invocation (or use) of RESOURCE. The invocation of RESOURCE begins 
with an access to RESOURCE which is an arrival of the same message M at RESOURCE and 
ends with a reply for the access which is a return of some result of the invocation. (See 
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the Figure 4 below.) 
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Figure 4 
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Our aim of using a one-at-a-lirrw guardian G is to control invocations of RESOURCE 
by parallel requests so that only one invocation of RESOURCE takes place at a time. In 
order to do so, if we have two concurrent requests, the end of the invocation by one request 
should always precede the beginning of the invocation of the other request. This intuitive 
description of the desired behavior of a one-at-a-time guardian can be described in terms 
of the order of the events request, access and reply introduced above. Suppose we 
have two requests, REQUESTj which is an arrival of a message M i at G, and REQUEST- which 
is an arrival of a message Mj at G. Then REQUEST, causes ACCESS k wnicn is an arriva) of 
M R at RESOURCE resulting in rep/ r /or[ACCESS k ], in this order (where k stands for either i 
or j). To ensure the one-at-a-time property of invocations of a resource, the following 
ordering relation must be satisfied: 



"if REQUEST, precedes REQUEST^, 
then r«pfy/or[ACCESSj] must precede ACCESS:". 

Since REQUEST k always precedes ACCESS, and ACCESS, always precedes 
rep/y-/or[ACCESS k ], the desired ordering relation can be expressed by the following 
diagram. 
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REQUESTj > REQUEST: 

I 



ACCESSj 



I 



rop/y-/or[ACCESSj] > ACCESSj 

rep/y-/or[ACCESSj] 

This behavior of the one-at-a-time guardian is formally described as a 
specification in Figure 5 below. Note that RESOURCE must be guaranteed to reply. 

<event: (one-at-a-time <= RESOURCE) 
<return: G* > 
<po$t-cond: (G is-a (ONE-AT-A-TIME RESOURCE)) » 

<for-events: REQUESTj, REQUESTj 

where REQUEST, = (G <= Mj), REQUESTj = (G <= Mj) 
<pre-cond: 

(G it-a (ONE-AT-A-TIME RESOURCE)) 
(RESOURCE is-guarantccd-to-reply) 
(REQUESTj precede! REQUESTj) > 

<caused-events: ACCESS,-, ACCESSj, repfy/brfACCESSj], rop/y/orfACCESS:] 
vbhere ACCESSj ■ (RESOURCE <= Mj), ACCESSj = (RESOURCE <=Mj)> 
<post-cond: 

(REQUESTj precedes ACCESSj) 
(REQUESTj precedes ACCESSj) 
(ACCESSj precedes reply- for[ ACCESSj]) 
(ACCESSj precedes r«jD/y-/or[ACCESSj]) 
(reply/or[ACCESSj] precedes ACCESSj )» 

Figure 5 A Specification for the One-at-a-Time Actor 

7. S ymbolic Evaluation of the Air Line 3^f**yj±*i?Jl_ KygJL*™ 

Our implementation of the air line reservation system is expressed by the following 
simple code: 

(create-flight a 8 ) = (one-at-a-time (create-flight-data s)) 
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(Equivalently, (create-flight = 8 ) = (one-at-a-time <= (create-flight-data <= s)). ) 

In this section we demonstrate that the above code meets the specification of the 
air line reservation system given in Figure i. Our method for the demonstration is symbolic 
evaluation. 

The symbolic evaluation of the code 

(one-at-a-time (ereate-flighi-data s)) 

reveals the following facts: 

1) an actor FO is created by (create-flight-data <= s), 

2) G is created by (one-at-a-time <= FO) and returned, and 

3) the two actors satisfy the following assertions immediately after the creation of G 

(FD w-o (FLIGHT-DATA (teat»-froe: e) (*ize: s))) 
(G is-a [ONE-AT-A-TIME FD)). 



/,' 
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This means that the flight actor is created as a one-at-a-time guardian G which contains a 
flight-data actor FD with 8 free seats. In what follows, we will establish that the 
one-at-a-time guardian G satisfies the specification for the flight actor in Figure 1. 

The <et*m;...>-clause in the specification for the flight actor in Figure 1 specifies 
the behavior of G in terms of the conceptual representation 

(G i«-o (FLIGHT {scau-frec:...)Uize:...))) 

(Notice that F in the specification for the flight actor is instantiated as G.) On the other 
hand, G is impjejnented as a on.-at-a-tim. guardian which contains the flight-data actor FD. 
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This means that we have two views of G and correspondingly two different conceptual 
representations are used to describe the state of G. In order to show that the 
implementation satisfies the specification, we need to establish some relation between the 
state of G expressed by 

(FLIGHT (teats- free:...) (site:...)) 
and the state of FD expresssed by 

{FLIGHT-DATA (seatt-free:...)(tize:...)). 
The relation we need is: 

"If G satisfies the assertion 

(G is-a (FLIGHT (seats- free: n) {the: s))) 
in a situation where G receives a message M, then FD always satisfies the 
assertion 

(FD it-a (FLIGHT-DATA (seats-free: n) (sizo: s))) 
in the situation where FD receives the same message M (through the 
on«-at-a-time guardian), and vice versa. " 

This relation is expressed formally as follows: 

<implementation-commentary: 

(G is-a (FLIGHT (scats- free: n) (size: s)» in S 
inhere S = Sit[(G<=M)] 
if-and-only-if 

(FD is-a (FLIGHT-DATA (scats- free: n) (size: s))) in S' 
where S' = Si t[(FD <= M)] >. 

Sit[E] expresses the situation where an event E takes place. The above implementation 
commentar y formally describes the basic idea of the implementation. It can be viewed as 
the counterpart of an "invariant" in parallel process environments, which was first 
introduced by [Hoare 19*72] to show correctness of implementation of data structures which 
are supposed to be used serially. 

It should be noted that the first-come-first-served based scheduling by the 
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guardian G guarantees the above relation. If the guardian does more complicated 
scheduling, the relation needed for the demonstration may not be so simple. For more 
general scheduling cases, see [Yonezawa77]. 

L Establishing the <evcnu (G <= (r<?*(?rtja-a-*oflf:)),.>c lause 

There are two cases to be considered. We only consider the (Ca*<?-2.„)-clause. 

Case-2: (G i*-a {FLIGHT (teats-free: n) (size; s))), (n > 0) 

The guardian G receives a (rc$crvc-a-scau) message M. To know the result of this 
event, the specification for one-at-a-time in Figure 5 is used. Since the flight-data actor 
FD is guaranteed to reply, the specification for one-at-a-time guarantees that the 
(reserve-a-seat:) message M is received by FD. To know the state of the flight-data actor 
FD at the time of the arrival of M, the above implementation commentary is used. Since 
f~^ the state of G at the time of the arrival of M at G is described as: 

(G i$-a (FLIGHT (seats-free: n) (size: s))), 

the state of FD at the arrival of M at FD is described as 

(FD is-a (FLIGHT-DATA (seats-free: n) (size: s))). 

Then the (Casa-<2...)-clause in the <«twii:..>clause of the specification for flight-data actors 
in Figure 3 is referred to. Since the precondition that FD must be used serially is satisfied 
(because FD is contained inside the one-at-a-time G), the (Ca*<*-2...)-clause of the 
specification for flight-data actors tells us that 

(1) (ok-its-reserved:) is returned, and 

(2) the state of FD is now expressed as: 

(FD U-a (FLIGHT-DATA (gcat-free: n - 1) (size: s))). 
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(1) is what the <r<?*i*rn.\.>clause in the specification for the flight in Figure 1 requires. Since 
the state of FD expressed as 

(FD i$-a (F LIGHT-DATA (*cat-frc<s: n - 1) (ms))) 

remains unchanged until the next message M' arrives at FD, by using the implementation 
commentary in the other direction this time, we know that the state of G remains unchanged 
as 

<G i*-a {FLIGHT ($eat$-fr<w n - 1) (mo: s))) 

until the message Kf arrives at G. This is what <naxt-condL„> clause in the specification 
for the flight actor in Figure 1 requires. Thus Case-2 is shown. Case-1 may be shown 
analogously. It should be noted that induction on the order of arrival of messages is used. 

IL Establishing the <eventt (G <= (cancd-a-s<>at:))..>cfou$e 
The demonstration for this event is analogous to that of I. 

HI. Establishing the </or-ot;omit:..>c l au se 

The event where the flight actor G receives a message means that the one-at-a-time 
guardian receives the same message. Suppose that M and M' arrive at G in this order. 
The specification for the one-at-a-time guardian specifies that M* is not received by FD 
until the reply from FD for M is completed. Therefore the reply to M' always takes place 
after the reply to M. This is what the specification requires. 

FVL, Establishing the C onfinement of the flight-data actor FD 

The discussion in I, II and III above assumes that no one can access the flight-data 
actor FD except through the guardian G. This assumption always holds because the 
flight-data actor FD created by (create-f!ight-data <= s) is never released outside the 
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on«-at-a-tim« actor. 



8- Further Work 



We are currently working to establish a coherent methodology for demonstrating 
that a distributed message-passing system will meet its specifications. By using the 
technique of symbolic evaluation, we would like to analyze the relationships and 
dependencies between modules in a distributed system. This approach will be instrumental 
in assisting us with the evolutionary development of distributed systems. 

We are also working on the application of procedural objects (such as actors) to the 
area of business automation. In order to replace paper forms and paper documents, we use 
"active" forms and "active" documents which are displayed as images on the TV terminal 
accompanied by procedures. Active forms and documents are sent from one site to another 
whereby clerks are requested to provide necessary information with the guidance of the 
accompanying procedures. Such procedures may also check the consistency of filled items 
and point out errors and inconsistencies to persons who are processing forms. Thus active 
forms and documents accompanied by procedures enormously increase the flexibility and 
security of message and document systems. Furthermore we propose to use the "language" 
of forms and documents as the basis for the user to communicate with the information 
processing system. One of the ultimate objectives in our research is to develop a 
methodology for the construction of real-time distributed systems which can be efficiently 
and effectively used by non-pro grammers. 
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